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The Crew Exploration Vehicle Parachute Assembly System (CPAS) project is currently developing an 
autonomous method to separate a capsule-shaped parachute test vehicle from an air-drop platform for use in 
the test program to develop and validate the parachute system for the Orion spacecraft. The CPAS project 
seeks to perform air-drop tests of an Orion-like boilerplate capsule. Delivery of the boilerplate capsule to the 
test condition has proven to be a critical and complicated task. In the current concept, the boilerplate vehicle 
is extracted from an aircraft on top of a Type V pallet and then separated from the pallet in mid-air. The 
attitude of the vehicles at separation is critical to avoiding re-contact and successfully deploying the 
boilerplate into a heatshield-down orientation. Neither the pallet nor the boilerplate has an active control 
system. However, the attitude of the mated vehicle as a function of time is somewhat predictable. CPAS 
engineers have designed an avionics system to monitor the attitude of the mated vehicle as it is extracted from 
the aircraft and command a release when the desired conditions are met. The algorithm includes contingency 
capabilities designed to release the test vehicle before undesirable orientations occur. The algorithm was 
verified with simulation and ground testing. The pre-flight development and testing is discussed and 
limitations of ground testing are noted. The CPAS project performed a series of three drop tests as a proof- 
of-concept of the release technique. These tests helped to refine the attitude instrumentation and software 
algorithm to be used on future tests. The drop tests are described in detail and the evolution of the release 
system with each test is described. 


I. Introduction 

T HE test program to design and validate the parachute recovery system for the NASA Crew Exploration Vehicle 
(CEV) includes ambitious objectives and complex test techniques. 5,6 This paper describes the development of 
one of these techniques. The CEV Parachute Assembly System (CPAS) development project desires to test the 
deployment and inflation of the parachute system under flight-like conditions in the wake of a representative 
forebody (or boilerplate capsule). Similar tests were performed on the Apollo program. However, the method used 
to deliver the Apollo boilerplate capsule to the test condition is infeasible due to the size of the Orion capsule and 
the available airframes. 7 CPAS has investigated an alternative technique that uses a modified Low Velocity Aerial 
Delivery (LVAD) system to extract a truncated boilerplate from a C-17 and deliver it to the test condition. The 
concept of operations for this technique will be described. Deployment of the boilerplate to the appropriate attitude 
required the development of a “Smart Release” algorithm. This algorithm will be defined and the test program to 
verify its utility will be described in detail. 
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II. Boilerplate Test Concept of Operations 

The full Orion outer mold line (OML) is incompatible with the available aircraft. For this reason, a Parachute 
Test Vehicle named PTV2 has been designed that maintains a representative diameter but has a truncated height. 
Figure 1 shows the difference between the Orion capsule and the test boilerplate. The height of the PTV2 has been 
reduced from 142 in. to 109 in. to allow extraction from a C-17. The parachute compartment of the PTV2 is 
representative of the actual Orion 
capsule. Prior to extraction from the 
aircraft the PTV sits on a custom 
extraction sled named the Cradle and 
Platform Separation System (CPSS). The 
CPSS is designed to interface with the 
aircraft and is also visible in Fig. 1. 

Figure 2 is a schematic of a typical 
Concept of Operations (ConOps) for the 
planned PTV2 tests. The PTV2 is 
initially fixed to the CPSS. The mated 
PTV2 and CPSS are extracted from a C- 
17 at roughly 145 KIAS and 25,000 ft- 
above Mean Sea Level (MSL) using a 
modified LVAD technique. Shortly after 
extraction, the mated system passes 
through the desired separation attitude. 

This condition is sensed by the on-board 
avionics package which issues a 
command to cut the lashings that hold the 
PTV2 to the CPSS. The desired 
separation attitude will be described in 
the following section. The separation of 
the PTV2 from the CPSS extends a static 
line that deploys the PTV2 programmer 
parachute. This sequence is intended to 
deliver the PTV2 to the desired test 
condition in a heatshield forward attitude. 

The CPSS descends under a recovery 
parachute system that is deployed by 
static line when the extraction chute is 
cut away. The timing of the cut-away and 
sizing of the recovery system must be 
designed to maintain an acceptable 
distance from the PTV2 during descent 
while also keeping the touchdown 
footprint within an acceptable area. 

The mid-air separation of the capsule shape from the platform is somewhat novel. The Apollo parachute test 
program had a customized aircraft that was capable of dropping the Apollo boilerplate in a heatshield down 
orientation directly from the rear of the aircraft. Other mid-air separation systems have had vehicles with active 
control systems or vehicle shapes that are more aerodynamically stable than the platform and capsule shapes. 7 
Neither the PTV2 nor the CPSS will have an active control system. Fortunately, experience with delayed load 
transfer extractions has shown that the attitude motion upon extraction is predictable, at least in a qualitative sense. 
This indicates that the mated vehicle motion is repeatable. The next section describes an algorithm that CPAS has 
developed to identify when the mated vehicle achieves an attitude that is favorable for positive separation. 

III. Description of the Smart Release Algorithm 

The mid-air separation described above was previously attempted on the CPAS Cluster Development Test 2 
(CDT-2). This test ended catastrophically due to cascading failures resulting from the collapse of the programmer 
parachute. 2 3 While the test condition was never achieved on CDT-2, a review of the extraction sequence determined 
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Figure 1. Comparison of Orion and PTV2 (from Ray and 
Morris 7 ). The PTV2 is a truncated Orion boilerplate capsule 
designed for extraction from a C-l 7 aircraft. 



Figure 2. Concept of Operations for PTV2 tests (after Ray and 
Morris 7 ). The PTV2 is extracted from the aircraft atop the CPSS. 
Shortly after extraction, the two bodies separate and the PTV2 
descends to the test condition under a static-line deployed 
programmer. The CPSS descends under its own recovery parachute 
system. 


that the separation attitude was unpredicted but desirable. 

Figure 4 shows the delivery of the CDT-2 boilerplate to 
the heatshield forward orientation upon separation from 
the CPSS. An accident investigation determined that the 
PTV wake and presence of stabilization parachutes 
contributed to the collapse of the programmer. 3 The 
CPAS project concluded that refinements to the 
separation sequence were required to avoid the 
programmer collapse and ensure that the motion 
observed on CDT-2 is repeated on future tests. Other 
refinements to the PTV2 outer mold line were applied to 
reduce snag hazards and improve the likelihood of 
successful parachute deployment. 

The motion of an LVAD pallet in a delayed load Figure 3. CDT-2 Separation. The previous attempt at 
transfer extraction is fairly predictable if the center-of- a mid-air boilerplate/platform separation momentarily 
gravity, mass, inertia tensor, and aerodynamics of the achieved the desired orientation. 
extracted pallet are known. During the first few seconds 

after extraction, most of the attitude motion occurs in the pitch plane. Extractions with a delayed Extraction Force 
Transfer Coupling (EFTC) release will typically exhibit a slight pitch-up as the pallet exits the aircraft ramp. This 
slight pitch-up is followed by a more dramatic pitch down and oscillation in the pitch plane. This behavior is 
depicted in the lower left-hand plot in Fig 4. The trajectory traces and numerical values in Fig. 4 are specific to the 
EDU-A-TSE-01 test series to be described below. The actual input parameters to the algorithm will depend upon 
PTV2 test trajectory predictions. Review of the CDT-2 test determined that the best time to separate the two bodies 
in order to repeat the CDT-2 separation is near the bottom of one of these pitch cycles. This occurs at the local 
minimum of the pitch angle and at the change in sign of the pitch rate from negative to positive. 



T riggerwhen one of three conditions is met 


Pitch: -40° < 6 < -10° 

AND Pitch Rate: 0 deg/s < Q < 1 0 deg/s 
AND Time (Ramp Clear): > 0.5 s 


OR 

OR 


Roll: |^| >20 (Roll not accurately 
modeled in currentsim) 

AND Time (Ramp Clear): > 0.5 s 


Time (Ramp Clear): > 6 s 



Figure 4. Smart Release Algorithm. The Smart Release algorithm is designed to release the PTV2 when desired 
pitch and pitch rate conditions are met. Maximum time and allowable roll angle serve as back-up conditions to 
release the PTV2 if the optimum conditions are never observed. Numerical values in this figure are specific to the 
EDU-A-TSE-01 test series and may not apply to PTV2 tests. 
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CPAS determined that the optimum release condition would be a function of the pitch angle and pitch rate. 
Therefore, CPAS engineers developed an algorithm to monitor the pitch and pitch rate of the mated PTV2/CPSS 
vehicle and identify the instant when both of these parameters are within acceptable limits. The pitch and pitch rate 
motion are sensitive to the mass properties and aerodynamics of the vehicle. Precise prediction of the motion 
requires high fidelity aerodynamic coefficients and accurate mass properties. Engineers anticipated the potential for 
test vehicles with various OMLs and mass properties. For this reason, the Smart Release algorithm was designed to 
allow flexibility in the selection of the acceptable pitch and pitch rate ranges. 

A robust separation algorithm would also include contingency release conditions. Experience had shown that 
some delayed-EFTC-release extractions exhibited significant roll within a few seconds of extraction. A large roll 
angle would make it difficult to achieve the heatshield forward orientation. Therefore, the Smart Release algorithm 
includes a roll limit. If the roll angle exceeds the defined limit, then a release is inititated. The intent is to release the 
PTV2 before an undesirable roll angle is achieved, even if the pitch attitude is sub-optimal. A maximum time 
condition was included in the algorithm to ensure that separation occurred even if the optimal pitch attitude was 
never achieved. Finally, a minimum time is required to provide adequate distance from the aircraft before the PTV2 
is released. 

Pseudocode for the Smart Release algorithm is included below: 

if time > minimum_time 

if (min_pitch < pitch < max_pitch) AND (min_pitch_rate < pitch_rate < max_pitch_rate ) 
RELEASE 

else if (abs (roll) > max_roll) 

RELEASE 

else if (time > maximum_time) 

RELEASE 

end 

end 

where the max and min values are configured by the test team to achieve the desired release attitude. The Smart 
Release algorithm described above provides versatility in defining the desired release orientation and is robust 
enough to ensure release if the actual extraction dynamics are off-nominal. 

IV. Testing the Smart Release Algorithm 

The algorithm described above was tested in three ways. The software algorithm was coded in MATLAB and 
used to process both flight data and simulation data. The algorithm was coded into the avionics system and ground 
tested with a set of programmed test inputs (PTIs) and a library of simulated trajectories. Finally, a series of three 
drop tests were performed that included primary objectives aimed to test the CPAS Generation II avionics system 
including the Smart Release algorithm. 

A. Testing of a Software Implementation of the Smart Release Algorithm 

The first step in the algorithm testing was a proof-of-concept phase intended to verify the utility of the algorithm. 
A MATFAB version of the Smart Release logic was coded and used to post-process data collected on previous drop 
tests. The algorithm was successfully able to identify the targeted minimum pitch angle by monitoring the recorded 
pitch and pitch rate histories. The testing evaluated multiple values of the user-configurable limits on pitch, pitch 
rate, roll, and time with flight data from multiple Generation I CPAS tests. At this stage of testing CPAS engineers 
observed that, for some tests, the pitch rate data was much noisier than the pitch data. This raised a concern that the 
algorithm might fail to correctly detect when the desired orientation had been reached because the instantaneous 
pitch rate data was unreliable. This phenomenon was pronounced on tests involving the separation of a dart-shaped 
vehicle from a cradle-monorail pallet. Historically, pallet and weight-tub drop tests had shown only modest noise in 
the pitch rate channel. Since the noise characteristics of the eventual boilerplate/pallet configuration were not 
understood, the project decided to add a filter to the pitch rate channel to smooth the data prior to processing with 
the algorithm. Figure 5 shows an example of one of these tests and the effect of the filter on removing the false- 
detection of the release orientation. This test was designed to detect the initial peak in pitch using pitch limits of 0° 
and 20° and pitch rate limits of 0°/s and -0.5°/s. Roll and time limits were selected so that they would not be a factor 
in the detection. Figures 5b and 5d show the noise in the pitch rate channel and how it might lead to a false trigger 
condition near 1.1s. The filtered data was more reliable in detecting the actual peak pitch at 2.2 s. 

Additional testing was performed on simulation data. This type of testing served two functions. The first was to 
test the Smart Release algorithm with a wider variety of attitude histories than were available in the existing flight 
data. Extraction trajectories were generated with the Decelerator System Simulation Application (DSSA). 1,2 
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False trigger 
due to noise 

Correct trigger 


Figure 5. Smart Release testing on previous flight data. The Smart Release algorithm was applied to recorded 
flight data to test the functionality on test-like data. Noise in the pitch rate data can create false trigger 
conditions. (After an unpublished figure by Kristin Bledsoe of the Engineering & Science Contract Group.) 

No noise was modeled in the simulation data. However, simulations were useful for creating extreme cases that were 
not present in the available test data. 

A second purpose for performing the simulation tests was to verify the accuracy of the MATLAB 
implementation of the Smart Release logic. The planned drop tests required 6-Degree-of-Freedom simulation in 
DSSA for prediction of test trajectories. A Monte Carlo analysis of the test trajectories was performed due to 
uncertainty in many of the test parameters. The MATLAB version of the release logic was included in the CPAS 
analysis Monte Carlo tool 4 so that the Smart Release condition could be evaluated on the dispersed extraction 
attitude histories. The Monte Carlo trajectories were useful in confirming an appropriate range for the Smart Release 
logic inputs. The limits on pitch, pitch rate, roll, and time were required to be broad enough to ensure that the trigger 
condition was satisfied during the actual flight but not so broad that the logic triggered before the desired condition 
was met. Figure 6 shows the Monte Carlo DSSA pitch and pitch rate results. The release point of each dispersed 
cycle is plotted as a small circle on the pitch and pitch rate histories. The grouping of the release points shows that 
every dispersed cycle released at the desired event, namely, the minimum of the first pitch cycle using pitch limits of 
-10° to -40° and pitch rate limits of 0° to 10°. 
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The results of these tests confirmed that the Smart Release algorithm was sound. CPAS engineers performed 
additional testing to verify the implementation of the algorithm in the avionics system and its performance when 
processing actual data from the flight sensors. 


□SSA Monte Carlo (500 Cycles, T races 0-20 shown): Smart Release 
Pitch Rate vs. Time 



Time,s 

Figure 6. Smart Release with Monte Carlo simulation. Appropriate pitch and pitch rate limits were 
determined through Monte Carlo analysis. Here all dispersed trajectories triggered the Smart Release logic at 
the same trajectory event. 


B. Ground Testing of the Avionics Implementation of the Smart Release Algorithm 

The Generation II CPAS Avionics system includes a National Instruments Compact Reconfigurable 
Input/Output (CRIO) Field Programmable Gate Array (FPGA) controller. A Microstrain 3DM-GX1 orientation 
sensor was initially chosen as the source for attitude data. The avionics system included a redundant set of sensors 
and controllers. The Smart Release algorithm was coded in the avionics controller and tested with manual PTIs and 
by feeding flight data and simulation data through the avionics system. This phase of testing was not as extensive as 
originally planned due to time constraints and other priorities in developing the Generation II CPAS avionics 
package. A post-flight review of the first drop test uncovered implementation issues and additional ground testing 
with the flight hardware was performed. 

The Smart Release algorithm as coded in the CRIO controller was tested by feeding artificial flight data through 
the avionics. This data included previous flight data, simulation data, and specially designed test input data files. 
This artificial data was intended to provide a wide variety of possible orientation histories. This was similar to the 
approach taken with the MATLAB implementation. Trigger limits could also be tailored for simulated data in order 
to test each possible path through the logic. The specially designed input data files were created to investigate the 
behavior of the Smart Release logic at the various gates in the logic path. For example, the Smart Release logic 
might evaluate whether a given parameter is strictly less than a limiting value. These special inputs data files were 
used to verify the expected behavior of the logic when the test parameter was exactly equal to the limiting value. 
Using these artificial orientation histories, it was possible to test every possible path through the Smart Release 
logic. Engineers evaluated the performance of the CRIO implementation of the algorithm by manually verifying that 
the test triggers occurred when expected (based on the custom orientation histories) and by comparing the results 
with trigger times determined by the MATLAB implementation of the algorithm. 

Physical testing was conducted by fixing the orientation sensors to a platform that could be maneuvered to 
various orientations. The intent of this phase of testing was to verify acceptable performance of the Smart Release 
algorithm with data collected from the sensors to be used in flight. This type of hardware-in-the-loop testing can 
identify unanticipated issues with sensor interfaces and data processing. The algorithm testing with the flight 
hardware provided confidence that the system would perform as planned in the upcoming drop tests. 
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C. Flight testing of the Smart Release Algorithm 

The algorithm verification and ground testing described above indicated that the Smart Release logic was ready 
for testing in flight. The CPAS project performed a series of three drop tests with the goal of verifying the 
effectiveness of the Smart Release system for use on a PTV2/CPSS test. The three tests were designed to test the 
Generation II CPAS avionics system by progressively increasing the responsibility of the new system in performing 
the test sequencing. An additional and equally valued test objective was the collection of rate-of-descent data for 
two CPAS Main parachutes. The initial portion of the test was intended to simulate the PTV2/CPSS ConOps. None 
of the tests planned for the actual mid-air separation of two bodies. Instead, a Type V LVAD pallet was outfitted 
with a weight tub and honeycomb structure that roughly mimicked the mass and aerodynamics of a mated 
PTV2/CPSS vehicle. The Smart Release firing command activated a set of flash bulbs instead of initiating a pyro- 
mechanical cutter as is anticipated with the PTV2/CPSS. Figure 7 is a schematic of a typical EDU-A-TSE-01 series 
test. Each of the tests used the test vehicle described above. The vehicle was extracted from a C-130A aircraft at 
roughly 20,000 ft-MSL. In the PTV2/CPSS ConOps the vehicles are expected to separate shortly after extraction, 



Figure 7. Smart Release air drop test schematic. Three drop tests were performed to verify the performance of 
the Smart Release logic and collect data on the CPAS Main parachutes. No vehicle separation was planned for 
these tests. The avionics svstem fired flash bulbs when the target orientation was achieved. 

while the CPSS is still attached to the extraction parachute. In the EDU-A-TSE-01 series, flash bulbs were fired by 
the Generation II avionics system when the Smart Release condition was detected. After approximately ten seconds, 
the extraction parachute repositioned to four attach-points on the rear of the test vehicle to orient the test article for a 
smooth transition to the programmer parachute. Roughly 30 seconds after exiting the aircraft, the extraction 
parachute was cut away and a 26-ft programmer was deployed to achieve a dynamic pressure of roughly 50 psf at 
deployment of the test parachutes. Sixty seconds after exiting the aircraft, the programmer was cut away and two 
CPAS Main parachutes were deployed and inflated through two reefed stages to the full open configuration. The 
three EDU-A-TSE-01 tests followed the same Concept of Operations with minor adjustments to the release altitude 
to manage touchdown footprint in response to test day winds. The results of the three EDU-A-TSE-01 tests will be 
described in sequence. 
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1. Test EDU-A-TSE-01A 

EDU-A-TSE-01A was conducted on October 2 nd , 2009 at the Yuma Proving Grounds (YPG), Arizona. The test 
vehicle was extracted from a C-130A aircraft at an altitude of 21,574 ft-MSL and a true airspeed of 342 ft/s. The 
programmer parachute deployed and inflated successfully. The CPAS Mains exhibited nominal deployment and 
inflation. Descent under the Main parachutes was as expected. 

While the test executed as planned, review of the data revealed that additional work was needed to mature the 
avionics system to the desired level of fidelity. This was the first flight of the Generation II system and the need for 
refinements was not unexpected. The test data revealed three primary problems that affected Smart Release 
performance: 

1) There was significant disagreement in the measurements and trigger times recorded by the redundant 
systems. 

2) There was notable lag between the occurrence of the desired orientation and the recognition of the 
condition by the avionics system and the issuance of the firing command. 

3) The system erroneously processed filtered roll rate instead of filtered pitch rate. 

Item 3 was the easiest to fix. Figure 8 depicts the time history of the Smart Release inputs and output for both 
systems. The difference in the recorded pitch angles between the two systems is visible. The test data was processed 
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Figure 8. EDU-A-TSE-01A Smart Release performance assessment [FIGURE TO BE REDRAWN PRIOR 
TO PUBLICATION]. The input orientation measurements recorded by the two systems differ considerably. 
Each system detected the Smart Release condition at a different time. 


with the MATLAB version of the Smart Release logic for comparison. Since each system received different 
orientation data, the MATLAB Smart Release logic detected the release condition at a different time on each system. 
It should be noted that the two systems were designed to be identical, with independent sensors located in the same 
location and in the same orientation. In Fig. 8 it is clear that the actual trigger times do not agree with the MATLAB 
detected trigger conditions. Moreover, it is not clear from the data traces which test condition caused each system to 
trigger. The orientation sensor provided a variety of available output data packages. The generic names of the output 
variables, ‘X-rate’, ‘Y-rate’, and ‘Z-rate’ were misinterpreted when translated to Euler angle rates. The 
interpretation also depended on the orientation in which the sensor was mounted on the test vehicle. The size of the 
test vehicle made it impractical to perform hardware-in-the-loop testing of the vehicle after sensors were mounted 
and connected to the data collection system. This problem was corrected with a simple software modification. 
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The other issues were more difficult to diagnose and correct. To further assess the performance, the error 
described above was duplicated in the MATLAB logic to determine if the system performed as expected given that 
it was processing roll rate data instead of pitch rate data. Figure 9 was used to evaluate the performance of the Smart 
Release system under these assumptions. In Fig 9a, the MATLAB logic determined that the pitch and roll-rate 
values did not simultaneously satisfy the pitch and pitch-rate conditions so the system should have triggered when 



Figure 9. EDU-A-TSE-01A Smart Release MATLAB reconstruction [FIGURE TO BE REDRAWN 
PRIOR TO PUBLICATION]. System A does not appear to trigger at the appropriate time. Each system 
detected the Smart Release condition at a different time. 

the roll limit was exceeded at roughly 1.7 s. However, it is clear that the system did not actually trigger until roughly 
one second later. Figure 9b shows that the B-system sensors gave measurements that momentarily satisfied the pitch 
and pitch-rate limits. However, MATLAB detected the desired condition at 0.47 s and the flight system did not 
detect it until 0.59 s. The system A error was tracked to a problem with the data logging rate and lagging 
performance of an internal error checking routine. The system B problem was tracked to an inadequate filter 
processing rate. These issues may not have been uncovered during pre-flight testing because this testing focused 
specifically on the smart release logic and only a subset of the data logging tasks were performed. 

These problems were addressed by optimizing the data logging rate and logic testing frequencies of the FPGA. 
The CPAS avionics and analysis teams agreed on a set of minimum synchronization and trigger requirements that 
were adequate for collecting data for extremely short duration testing events (such as drogue inflations) while not so 
stringent as to over-burden the avionics controller. Those requirements were: 

1) The time elapsed between the achievement of the Smart Release condition and the firing command shall be 
less than or equal to 0.02 s. 

2) The sensors on a single avionics string shall be synchronized to within 0.01 s. 

3) The redundant avionics strings shall be synchronized with each other to within 0. 1 s. 

The final problem to resolve was the disagreement in the basic input measurements between the two systems. 
Because the roll measurement and the angular rates agreed between the two systems, but the yaw and pitch angles 
did not, the CPAS analysts suspected a possible problem with the kinematic integration of the Euler angles. The yaw 
angle from the orientation sensor was determined with a magnetometer. The test vehicle contained a large amount of 
ferrous metal and was subject to varying electromagnetic environments as it was extracted from the aircraft. It 
seemed quite possible that any initial difference in the yaw angle measured by the two sensors would propagate 
through the pitch angle as the angular rates were integrated within the sensor. For the second test, the CPAS avionics 

9 

American Institute of Aeronautics and Astronautics 


and analysis teams decided to place the orientation sensor in vertical gyro mode in an attempt to isolate the pitch and 
roll readings from the yaw measurement. The avionics system was configured to record a set of Crossbow Nav440 
GPS/IMU units to provide an independent source of orientation data. In addition to these sources, a Novatel SPAN- 
SE GPS/IMU system was mounted on the test vehicle for each test. This instrument package requires post- 
processing and is not suitable for real-time attitude determination. This was a unique application of the SPAN-SE 
and the post-processed data was not available to support decisions prior to the second test. Finally, the avionics 
software was modified to log the state of each of the tests in the Smart Release logic. This addition to the data set 
allowed engineers to compare the state of the logic against the recorded orientation data and determine why the logic 
did or did not trigger. 

Additional and more extensive ground testing of the avionics system was performed both at the Johnson Space 
Center and on the actual test vehicle in Yuma. This testing was similar to the ground testing described above but was 
performed while the full system was operating and recording all channels. Recorded flight data, sim data, and 
artificial PTI data were processed by the Smart Release logic and results were evaluated against the time accuracy 
and synchronization requirements described above. 

Engineers attempted to mimic the orientation history provided by the sensors during live tests by manually 
manipulating an orientation sensor assembly. It was not possible to completely imitate the orientations and 
accelerations of the test vehicle with the available test hardware. The second round of ground testing showed 
significant improvement to the entire avionics system and to the Smart Release logic performance. Concern over the 
performance of the orientation sensors themselves lingered. However, the improvements witnessed in the ground 
testing had improved confidence in the data acquisition system. The desire to collect data for the other test objective 
(CPAS Main rate-of-descent performance) and the potential loss of test range availability compelled the project to 
proceed with the second test. A re-test of the system with the additional orientation sensors included for comparison 
would provide the data needed to resolve the sensor issue. 

2. Test EDU-A-TSE-01B 

EDU-A-TSE-01B was conducted on December 1 st , 2009 at the Yuma Proving Grounds (YPG), Arizona. The test 
vehicle was extracted from a C-130A aircraft at an altitude of 21,175 ft above Mean Sea Level (MSL) and a true 
airspeed of 321 ft/s. The programmer parachute deployed and inflated successfully. The CPAS Mains exhibited 
nominal deployment and inflation. Descent under the Main parachutes was as expected. 
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Figure 10. EDU-A-TSE-01B Smart Release performance assessment [FIGURE TO BE REDRAWN 
PRIOR TO PUBLICATION]. System B triggers as expected. However, the orientation data was found to be 


erroneous. 
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a) 



Performance of the Generation II avionics system was notably improved over test EDU-A-TSE-01A, but 
additional challenges remained. With regard to the Smart Release objectives, there were two important issues: 

1 ) System A did not perform as expected due to a voltage drop-out. 

2) System B did not trigger at the desired attitude. 

This first problem affected the entire A-string of the avionics system and was not related to Smart Release. This 
problem was a hardware issue that was resolved prior to additional testing. The second problem was traced to the 
orientation sensor. The Smart Release logic itself performed as expected on this test. Figures 10a, 10b, and 10c show 
the pitch, pitch rate, and roll histories for the first seven seconds of the test. Figure lOd shows the logic state flags 
that were added to the avionics after test EDU-A-TSE-01A. The logic performed as would be expected given the 
orientation data and triggered on an excessive roll angle at 5.42 s. The pitch and pitch rate conditions were not 
simultaneously met prior to the time that roll exceeded its limit. However, the large roll angle was not observed on 
the test video. 

The orientation from the GX-1 
sensor was compared against that of the 
Nav440 sensor and the Novatel SPAN- 
SE. The GX-1 was found to disagree 
considerably in the pitch channel from 
the Nav440 and the SPAN-SE. Figure 
11a shows a comparison of the pitch 
histories. The GX-1 shows a non- 
physical pitch down of the test vehicle 
before it exits the aircraft ramp. The 
difference in pitch angle grows to about 
40° within a few seconds and 
eventually returns to agreement with 
the other sources. A similar 
disagreement was observed in the roll 
data. Curiously, the angular rate data 
agreed well with the other data sources. 

To investigate the problem, the angular 
rates were integrated independently 
using the appropriate kinematic 
equations of motion. The result is 
shown in Fig. lib. The integrated angle 
agreed fairly well with the Euler angles 
measured by the Nav440 and SPAN- 
SE, at least for the initial motion. The 
agreement of the other orientation 
sensors and the integrated rates led the 
CPAS analysts to believe that the GX-1 
sensor was unreliable in this 
application. The GX-1 output mode 
employed in these tests utilized an 
internal algorithm that was meant to 
filter out transient linear accelerations. 

After additional ground testing, the 
avionics and analysis teams reached a consensus that the strong longitudinal acceleration associated with the 
extraction event overwhelmed this filter or caused the filter to overcompensate for the short onset acceleration. 

The agreement of the Nav440 and SPAN-SE sensors suggested that there might be an effective alternative to the 
GX-1. The SPAN-SE is not suitable for real-time processing. Other solutions that were investigated included, 
determining an alternate data package from the GX-1 suite, modifying the internal GX-1 filter settings, and 
independently integrating the GX-1 angular rates in real-time within the Smart Release algorithm. Ultimately, the 
CPAS project decided to replace the GX-1 units with the Nav440 units as the source for Smart Release orientation 
data. 


b) 



Figure 11. EDU-A-TSE-01B Pitch behavior after extraction 
[FIGURE TO BE REDRAWN PRIOR TO PUBLICATION]. The 

GX-1 sensor disagrees considerably with the other sources of pitch 
data. Integrating the GX-1 rates provided more reasonable results. 
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Figure 12. EDU-A-TSE-01B Smart Release performance assuming Nav440 inputs [FIGURE TO BE 
REDRAWN PRIOR TO PUBLICATION]. The post-flight application of the Smart Release algorithm to the 
EDU-A-TSE-01B Nav440 data indicates that the Smart Release logic would have triggered at the appropriate 
attitude. 

The EDU-A-TSE-01B data collected from the Nav440 was processed with the MATLAB Smart Release 
implementation. Figure 12 shows the pitch, pitch rate, and roll histories. The MATLAB analysis indicated that the 
Smart Release would have been triggered at the desired point near the minimum of the first pitch-down. The desired 
pitch and pitch rate conditions occurred simultaneously at roughly 1.7 seconds and an excessive roll angle was not 
observed. This result also agreed well with the pre-flight predictions of the extraction and Smart Release trigger. 

3. Test ED U-A- TSE- 01 C 

EDU-A-TSE-01C was conducted on February 9 th , 2010 at the Yuma Proving Grounds (YPG), Arizona. The test 
vehicle was extracted from a C-130A aircraft at an altitude of 20,528 ft above Mean Sea Level (MSL) and a true 
airspeed of 334 ft/s. Unfortunately, the EFTC device failed to release, which in- turn prevented the deployment of the 
programmer and CPAS Main parachutes. The test 
vehicle crash landed under the extraction parachute. 

The avionics system was destroyed. Remarkably, 

CPAS engineers were able to recover a few seconds of 
data from the storage device. The EFTC release is a 
mechanical process and is not activated by the avionics 
system. Test video indicates that the avionics system 
was operational during the test. Four flashbulbs were 
mounted on the test vehicle and were commanded to 
fire by the avionics system when the smart release 
conditions were satisfied. Figure 13 shows the firing of 
these flash bulbs at 1 .46 seconds after the vehicle clears 
the aircraft ramp. 

Fortunately, the portion of the test data that was 
recovered includes the first few seconds of the drop 
test. This is sufficient to assess the performance of the 
refined Smart Release logic. Figure 14 shows the 
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Figure 13. EDU-A-TSE-01C Smart Release trigger. 

Four flash bulbs mounted on the test vehicle were fired 
by the avionics system when the release condition was 
sensed. 



Nav440 sensed pitch, pitch rate, and roll measurements. The smart release logic indicators added to the avionics 
system after test EDU-A-TSE-01A indicate that the avionics system recognized satisfactory pitch and pitch rate 
conditions at 1.41 seconds after clearing the aircraft ramp. This event and the flashbulb fire are indicated on Fig. 14. 
Also indicated is the MATLAB solution for trigger time. These events coincide with the minimum pitch down 
observed in the data. Currently available data does not allow complete synchronization of the aircraft video ramp 
clear event with the pin-pull event that is recorded by the avionics system at ramp clear. This information would 
allow further synchronization of the flash bulb fire (based on video) with the Smart Release command (based on 
avionics data). Nevertheless, Fig. 14 suggests that the Smart Release logic performed successfully on test EDU-A- 
TSE-01C. 
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Figure 14. EDU-A-TSE-01C Smart Release Performance. Evaluation of the recovered EDU-A-TSE-01C data 
indicates successful performance of the Smart Release logic. 

The EDU-A-TSE-01 series were a test technique and avionics development project that included several 
engineering challenges. While not all of the test objectives were achieved, the Smart Release algorithm was 
demonstrated to perform as expected by the final test. Additional confidence in the system may be gained by 
passively executing the release logic on future pallet-like tests that are planned before the PTV2 test series. 

V. Conclusion 

The Smart Release algorithm developed by CPAS is intended to be employed on the PTV2 boilerplate tests to verify 
the performance of the Orion parachute system. The size of the Orion capsule and limited availability of modifiable 
aircraft lead the CPAS project to develop a technique to deploy the PTV2 using a modified platform extraction. The 
Smart Release algorithm has been developed to track the extracted vehicle orientation until a desired separation 
condition is met. This paper outlined the testing that was performed on this system. The testing was designed to 
build confidence in the technique before employing it on a PTV2 test. The development of the Smart Release system 
and the Generation II avionics system included significant challenges. CPAS engineers met these challenges and 
ultimately delivered a system that is able to initiate the separation of the PTV2 and CPSS when a desired orientation 
is met. Additional tests scheduled before the PTV2 series provide an opportunity to gain further confidence in the 
system. 
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